home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / cip / cip-minutes-90july.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  201 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Claudio Topolcic/BBN
  7.  
  8. CIP Minutes
  9.  
  10. Agenda
  11.  
  12.  
  13.    o ST-II specification
  14.  
  15.       -  Identify remaining issues
  16.       -  Discuss remaining issues
  17.       -  Resolve remaining issues
  18.       -  Assign writing tasks
  19.  
  20.    o Connection oriented protocol research collaboration
  21.       -  Discuss possible collaboration efforts
  22.  
  23.  
  24. The CIP Working Group met during all five Working Group sessions.  Our
  25. primary goal for this meeting was to resolve the remaining open issues
  26. in the ST-II protocol specification; three sessions were dedicated to
  27. this effort.  In the other two sessions we discussed collaborative
  28. experiments on connection-oriented internet protocols.
  29.  
  30. A draft of the ST-II specification was distributed and discussed at the
  31. previous IETF. Several issues were resolved then and new ones uncovered.
  32. Prior to the current meeting, Charlie Lynn distributed an updated draft
  33. incorporating the results of the previous meeting plus ensuing
  34. teleconferences and email.  We discussed the changes and unresolved
  35. issues as follows:
  36.  
  37.  
  38.    o Precedence is a per-connection characteristic, and is negotiated in
  39.      the flowspec.  There is a separate priority on each data packet to
  40.      allow for layered coding schemes within one stream.
  41.    o We agreed that all header and option chunks should have 32-bit
  42.      alignment, including 32-bit entities within chunks, to efficiently
  43.      accommodate machine architectures with that constraint.
  44.    o The REFUSE and REROUTE negative response messages will be combined
  45.      into one and the receiver will use the reason code to determine
  46.      what action is appropriate.
  47.    o If ranges of packet rate and size are offered, agents along
  48.      separate branches of a connection might choose incompatible
  49.      combinations each of which meets the minimum product requirement.
  50.      Intermediate agents must keep track of flowspecs along each branch,
  51.      so resolution can be left to the application.
  52.    o To insure that a CHANGE won't cause the existing connection to
  53.      break, the flowspec ranges must include the existing settings.
  54.    o It is not considered an error if the next hop on a path is out the
  55.      same interface as the previous hop, to allow relay multicasting.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.    o The current specification does not allow a uniform way on all
  65.      control messages to determine the intended client.  New fields are
  66.      to be added to the control message header to allow this.
  67.    o A mechanism for grouping streams is provided, but their use is not
  68.      yet well enough understood, and will therefore, be left to
  69.      experiment.
  70.    o To make use of IP encapsulation paths between ST agents not
  71.      directly connected, the ST routing table must be extended.
  72.    o The current flowspec definition does not allow specifying a
  73.      variable-rate requirement nor discrete steps in place of a range.
  74.      There are provisions to define new flowspec versions as we learn
  75.      what is needed through experiments.
  76.  
  77.  
  78. Writing assignments were also issued for sections of the document that
  79. are incomplete but not controversial.  The draft is to be ready for
  80. submission as an Internet Draft in two weeks, followed by submission as
  81. an RFC after a comment period.  The protocol will have ``Not-Recommended
  82. Experimental'' status while the CIP Group and others conduct
  83. experiments.
  84.  
  85. Collaboration
  86.  
  87. On Wednesday, we heard status reports on experimenters' plans.  Allison
  88. Mankin described her work to implement Lixia Zhang's Flow Protocol
  89. algorithms within the framework of the BSD OSI TP2 protocol.  She is now
  90. implementing the virtual clock mechanism in the BSD network drivers.
  91. Allison will test the protocol in the MITRE-DCA Testbed Network; she
  92. invites others to use the testbed, too.
  93.  
  94. Charlie Lynn described the collaboration of BBN and Washington
  95. University in St.  Louis to develop the ``COIP-kernel'' -- basically a
  96. new protocol family added into the BSD socket interface around which a
  97. variety of connection-oriented protocols could be implemented.  The
  98. kernel is to be done by the end of August, then during September BBN
  99. will develop a set of modules around the kernel to implement ST-II.
  100.  
  101. Paul McKenney told us about the traffic generators he is developing so
  102. that DARTnet experimenters can conduct repeatable experiments.  They run
  103. in user space and can be synchronized at multiple sites, injecting
  104. packets at the NIT, RAW_IP or transport level.  Measures are defined for
  105. both ``best effort'' and ``resource reservation'' types of protocols.
  106.  
  107. Finally, we discussed how members of the group might collaborate.
  108. Allison expressed interest in using the COIP-kernel to extend Flow
  109. Protocol testing to the DARTnet Sparcstation environment.  Paul's
  110. traffic generators may also be usable in the network testbed.
  111. Conversely, Paul might be able to incorporate Allison's DEC-bit code
  112. into the stochastic fair queuing algorithm.
  113.  
  114. Meeting action list
  115.  
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Casner              Rewrite sect 2 (& 2.1?)  in about 3 pages (may be ok
  125.                     now).
  126.  
  127. Everyone            Comment on whether sections 2.3 through 2.7 are
  128.                     complete.
  129.  
  130. Casner              Update old encapsulation text of sect 3.7.3.
  131.  
  132. Topolcic            Edit or rewrite section 3.7.5 on Robustness.
  133.  
  134. Lynn                Edit sect 3.7.6.  on Routing to simply list the
  135.                     things we expect from the routing function, but
  136.                     state that routing is not addressed here.
  137.  
  138. Topolcic            Edit or rewrite section 3.7.8.  on Groups of Streams
  139.                     to state that groups are a way of associating
  140.                     streams and to just list some possible uses of such
  141.                     associated groups.
  142.  
  143. Lynn                Produce text for section 3.7.9.  on the Source Route
  144.                     Option.
  145.  
  146. Lynn                Write a section in 4.3.1, FlowSpec that addresses
  147.                     the Burstiness parameter.
  148.  
  149. Lynn                Edit the paragraphs in section 4.3.1.  that describe
  150.                     LimitOnCost and LimitOnDelay to specify the units.
  151.  
  152. Topolcic            Rewrite section 4.3.5.3.  on Group Parameter to
  153.                     simply provide suggestions for the uses of Groups.
  154.  
  155. Lynn                Expand sect 4.4.14 on use of STATUS command for
  156.                     failure detection.
  157.  
  158. Everyone            Help find all the constants for inclusion in section
  159.                     4.5, Suggested Protocol Constants, and should
  160.                     suggest values.
  161.  
  162. Everyone            Help write section 6, Areas Not Addressed, and
  163.                     specifically to help draw up a list.
  164.  
  165. Everyone            Help identify subsets everywhere.
  166.  
  167. Schroder            Provide protocol exchange diagrams.
  168.  
  169. Everyone            Think of good way to simplify protocol
  170.                     demultiplexing; consider origin & target(s) of
  171.                     stream on same host.
  172.  
  173.  
  174.  
  175. Attendees
  176.  
  177.                                    3
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185. Stephen Casner           casner@venera.isi.edu
  186. Steve Deering            deering@pescadero.stanford.edu
  187. Kevin Fall               kfall@Berkeley.EDU
  188. Kathleen Huber           khuber@bbn.com
  189. Ajay Kachrani            kachrani%regent.dec@decwrl.dec.com
  190. Charles Lynn             clynn@bbn.com
  191. Allison Mankin           mankin@gateway.mitre.org
  192. Paul McKenney            mckenney@sri.com
  193. K.K. Ramakrishnan        rama%erlang.dec.com@decwrl.dec.com
  194. Zaw-Sing Su              zsu@tsca.istc.sri.com
  195. Claudio Topolcic         topolcic@bbn.com
  196. Sijiam Zhang             szhang@cs.ubc.ca
  197.  
  198.  
  199.  
  200.                                    4
  201.